Add WhenUpdatesCompleted to Foundry MemoryProvider to await async memory extraction - #653

Parity gap — superseded terminal state

The .NET WhenUpdatesCompletedAsync explicitly treats MemoryStoreUpdateStatus.Superseded as a successful terminal state (returns without error), mirroring Foundry service semantics where a superseded update is implicitly replaced by a newer one.

The Go implementation delegates to runtime.Poller.PollUntilDone, which only knows standard Azure LRO states and does not treat superseded as terminal. As a result, WhenUpdatesCompleted will keep polling past a superseded status until the service returns a different state or the context times out — diverging from the .NET behaviour.

The PR acknowledges this in the open design questions, but it is worth flagging explicitly since .NET has already shipped the fix:

// .NET — FoundryMemoryProvider.cs
if (status == MemoryStoreUpdateStatus.Completed || status == MemoryStoreUpdateStatus.Superseded)
    return; // treat superseded as success

Suggestion: before merging, consider either (a) using a custom PollingHandler / response classifier in the Azure Go SDK so the poller treats superseded as done, or (b) replacing PollUntilDone with a manual polling loop that mirrors .NET's WaitForUpdateAsync and explicitly handles superseded → success.

Parity gap — superseded terminal state not handled

The .NET WhenUpdatesCompletedAsync (FoundryMemoryProvider.cs) explicitly treats superseded as a success terminal state alongside completed:

if (status == MemoryStoreUpdateStatus.Completed || status == MemoryStoreUpdateStatus.Superseded)
{
    return;
}

This Go implementation delegates to runtime.Poller.PollUntilDone, which only knows about generic Azure LRO states (Succeeded, Failed, Canceled). The Foundry-specific superseded state is not a standard Azure LRO terminal state, so the poller will likely loop until ctx is cancelled if an update is superseded by a newer one.

The PR description flags this as a known follow-up, but callers awaiting in a test or workflow may hang silently. Consider adding an explicit doc note to the godoc comment warning that a superseded update will block until the context deadline, and linking to a tracking issue.

Parity gap — required vs optional pollingInterval

In the .NET implementation, WhenUpdatesCompletedAsync makes pollingInterval optional with a 5-second default:

public async Task WhenUpdatesCompletedAsync(
    TimeSpan? pollingInterval = null,     // defaults to 5 seconds
    CancellationToken cancellationToken = default)

The Go signature requires callers to pass an explicit pollingInterval:

func (p *MemoryProvider) WhenUpdatesCompleted(ctx context.Context, pollingInterval time.Duration) error

This is a minor ergonomics gap: callers must always choose a value rather than relying on a sensible default. Consider treating a zero pollingInterval as "use the default 5 s interval" to stay aligned with the .NET UX.

Parity gap — superseded terminal state not handled

The .NET implementation explicitly treats superseded as a success terminal state:

if (status == MemoryStoreUpdateStatus.Completed || status == MemoryStoreUpdateStatus.Superseded)
{
    return;
}

The Go implementation delegates polling to runtime.Poller.PollUntilDone from the Azure SDK, which only treats Succeeded / Completed as terminal success. If Foundry ever returns a superseded status for a polled LRO, PollUntilDone may spin indefinitely or return an error rather than treating it as success.

The PR description already flags this as an open question. For parity with .NET, superseded should be treated as a success outcome (the update was replaced by a newer one, so the net effect is the same). Consider wrapping the poller or post-processing the error to handle superseded as a no-op success.